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ABOUT THIS CHAPTER 


The Macintosh RAM Serial Driver and ROM Serial Driver are Macintosh device 
drivers for handling asynchronous serial communication between a Macintosh 
application and serial devices. This chapter describes the Serial Drivers in 
detail. 


You should already be familiar with: 


resources, as discussed in the Resource Manager chapter 

events, as discussed in the Toolbox Event Manager chapter 

the Memory Manager 

interrupts and the use of devices and device drivers, as described 
in the Device Manager chapter 

* asynchronous serial data communication 


eoeee 
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SERIAL COMMUNICATION 


The Serial Drivers support full-duplex asynchronous serial communication. Serial 
data is transmitted over a single-path communication line, one bit at a time (as 
opposed to parallel data, which is transmitted over a multiple-path 
communication line, multiple bits at a time). Full-duplex means that the 
Macintosh and another serial device connected to it can transmit data 
Simultaneously (as opposed to half-duplex operation, in which data can be 
transmitted by only one device at a time). Asynchronous communication means that 
the Macintosh and other serial devices communicating with it don't share a 
common timer, and no timing data is transmitted. The time interval between 
characters transmitted asynchronously can be of any length. The format of 
asynchronous serial data communication used by the Serial Drivers is shown in 
Figure 1. 


start data data slop stop 
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Frame 


Figure 1—-Asyuchronous Data Transmission 
Figure 1—Asynchronous Data Transmission 


When a transmitting serial device is idle (not sending data), it maintains the 
transmission line in a continuous state ("mark" in Figure 1). The transmitting 
device may begin sending a character at any time by sending a start bit. The 
start bit tells the receiving device to prepare to receive a character. The 
transmitting device then transmits 5, 6, 7, or 8 data bits, optionally followed 
by a parity bit. The value of the parity bit is chosen such that the number of 
1's among the data and parity bits is even or odd, depending on whether the 
parity is even or odd, respectively. Finally, the transmitting device sends 1, 
1.5, or 2 stop bits, indicating the end of the character. The measure of the 
total number of bits sent over the transmission line per second is called the 
baud rate. 


If a parity bit is set incorrectly, the receiving device will note a parity 
error. The time elapsed from the start bit to the last stop bit is called a 
frame. If the receiving device doesn't get a stop bit after the data and parity 
bits, it will note a framing error. After the stop bits, the transmitting device 
may send another character or maintain the line in the mark state. If the line 
is held in the "space" state (Figure 1) for one frame or longer, a break occurs. 
Breaks are used to interrupt data transmission. 
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ABOUT THE SERIAL DRIVERS 


Note: The extensions to the Serial Drivers described in this chapter were 
Originally documented in Inside Macintosh, Volumes IV. As such, the 
Volume IV information refers to the 128K ROM and System file version 
3.2 and later. The sections of this chapter that cover these extensions 
are so noted. 


There are two Macintosh device drivers for serial communication: the RAM Serial 
Driver and the ROM Serial Driver. The two drivers are nearly identical, although 
the RAM driver has a few features the ROM driver doesn't. Both allow Macintosh 
applications to communicate with serial devices via the two serial ports on the 
back of the Macintosh. 


Note: There are actually two versions of the RAM Serial Driver; one is for 
the Macintosh 128K and 512K, the other is for the Macintosh XL. If you 
want your application to run on all versions of the Macintosh, you 
should install both drivers in your application resource file, as 
resources of type 'SERD'. The resource ID should be 1 for the Macintosh 
128K and 512K driver, and 2 for the Macintosh XL driver. 


Each Serial Driver actually consists of four drivers: one input driver and one 
output driver for the modem port, and one input driver and one output driver for 
the printer port (Figure 2). Each input driver receives data via a serial port 
and transfers it to the application. Each output driver takes data from the 
application and sends it out through a serial port. The input and output drivers 
for a port are closely related, and share some of the same routines. Each driver 
does, however, have a separate device control entry, which allows the Serial 
Drivers to support full-duplex communication. An individual port can both 
transmit and receive data at the same time. The serial ports are controlled by 
the Macintosh's Zilog Z8530 Serial Communications Controller 

(SCC). Channel A of the SCC controls the modem port, and channel B controls the 
printer port. 


Data received via a serial port passes through a three-character buffer in the 
SCC and then into a buffer in the input driver for the port. Characters are 
removed from the input driver's buffer each time an application issues a Read 
call to the driver. Each input driver's buffer can initially hold up to 64 
characters, but your application can specify a larger buffer if necessary. The 
following errors may occur: 


e If the SCC buffer ever overflows (because the input driver doesn't read 
it often enough), a hardware overrun error occurs. 

e If an input driver's buffer ever overflows (because the application 
doesn't issue Read calls to the driver often enough), a software overrun 
error occurs. 


The printer port should be used for output-only connections to devices such as 
printers, or at low baud rates (300 baud or less). The modem port has no such 

restrictions. It may be used simultaneously with disk accesses without fear of 
hardware overrun errors, because whenever the Disk Driver must turn off 
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interrupts for longer than 100 microseconds, it stores any data received via the 
modem port and later passes the data to the modem port's input driver. 


Cm 
modem port modem port printer port printer port 
input driver output driver input driver output deiver 

sa = 


Figure 2-lnput and Output Drivers of a Serial Driver 


Figure 2—Input and Output Drivers of a Serial Driver 


All four drivers default to 9600 baud, eight data bits per character, no parity 
bit, and two stop bits. You can change any of these options. The Serial Drivers 


Support Clear To Send (CTS) hardware handshake and XOn/XOff software flow 
control. 


Note: The ROM Serial Driver defaults to hardware handshake only; it doesn't 
Support XOn/XOff input flow control—only output flow control. Use the 
RAM Serial Driver if you want XOn/XOff input flow control. The RAM 
Serial Driver defaults to no hardware handshake and no software flow 
control. 


Whenever an input driver receives a break, it terminates any pending Read 
requests, but not Write requests. You can choose to have the input drivers 
terminate Read requests whenever a parity, overrun, or framing error occurs. 


Note: The ROM Serial Driver always terminates input requests when an error 
occurs. Use the RAM Serial Driver if you don't want input requests to 
be terminated by errors. 


You can request the Serial Drivers to post device driver events whenever a 
change in the hardware handshake status or a break occurs, if you want your 
application to take some specific action upon these occurrences. 


Note: The extensions to the Serial Drivers described in the following 
paragraphs were originally documented in Inside Macintosh, Volume IV. 
As such, this information refers to the 128K ROMs and System file 
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version 3.2 and later. 


In the 128K ROM, a single new Serial Driver replaces the RAM and ROM Serial 
Drivers. 


Note: The new Serial Driver has a version number of 2. The old ROM driver 
had a version number of 0, and the old RAM driver a version number of 1. 


For best results, include the RAM Serial Drivers as resources of type 'SERD' in 
the resource fork of your application and continue to use RAMSDOpen and 
RAMSDClose. If the 128K ROM is present, the new driver is automatically 
substituted. 


The new Serial Driver verifies that the serial port is correctly configured and 
free; if not, the result code portNotCf or portInUse is returned. When opened, 
the Serial Driver defaults to hardware handshake on (as did the old ROM driver). 


Note: The Q & A Stack "Programming" section contains a thorough discussion 
of configuration errors. 


eeeClick on the X-Ref button, and refer to Q & A Stack,eee 


The Data Terminal Ready (DTR) line in the RS232 interface is now automatically 
asserted when the Serial Driver is opened; DTR is negated when it is closed. 
Control calls let you explicitly set the state of this line, as well as use it 
to automatically control the input data flow from an external device. 


New advanced control calls let you control the DTR line, set certain control 
options, and modify the translation of parity error default characters; they're 
described below. 


All control and status calls may be immediate. (For information about immediate 
calls, see the Device Manager chapter. ) 


The following bugs have been fixed: 


« The procedure RAMSDClose preserves mouse interrupts during its execution. 

« The execution of break and close routines is now synchronized to the 
current transmission. 

¢ Incoming clock pulses on the CTS line are now detected; if they're present, 
CTS interrupts are disabled. 

¢ If you open only the input channel of a driver, the Open routine checks 
to see if the necessary variables have been initialized and exits if they 
have not. 
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USING THE SERIAL DRIVERS 


Note: The information on Using the Serial Drivers described in the following 
paragraphs was originally documented in Inside Macintosh, Volume II. 


This section introduces you to the Serial Driver routines described in detail in 
the next section, and discusses other calls you can make to communicate with the 
Serial Drivers. 


Drivers are referred to by name and reference number: 


Driver Driver name Reference number 
Modem port input .AIn —6 
Modem port output .AOut -7 
Printer port input .BIn -8 
Printer port output .BOut -9 


Warning: You should not hard-code Reference numbers; instead, use the 
Device Manager to open the driver, then use the Reference numbers 
that it returns. 


Before you can receive data through a port, both the input and output drivers 
for the port must be opened. Before you can send data through a port, the output 
driver for the port must be opened. To open the ROM input and output drivers, 
call the Device Manager Open function; to open the RAM input and output drivers, 
call the Serial Driver function RAMSDOpen. The RAM drivers occupy less than 2K 
bytes of memory in the application heap. 


When you open an output driver, the Serial Driver initializes local variables 
for the output driver and the associated input driver, allocates and locks 
buffer storage for both drivers, installs interrupt handlers for both drivers, 
and initializes the correct SCC channel (ROM Serial Driver only). When you open 
an input driver, the Serial Driver only notes the location of its device control 
entry. 


You shouldn't ever close the ROM Serial Driver with a Device Manager Close call. 
If you wish to replace it with a RAM Serial Driver, the RAMSDOpen call will 
automatically close the ROM driver for you. You must close the RAM Serial Driver 
with a call to RAMSDClose before your application terminates; this will also 
release the memory occupied by the driver itself. When you close an output 
driver, the Serial Driver resets the appropriate SCC channel, releases all local 
variable and buffer storage space, and restores any changed interrupt vectors. 


Warning: The previous paragraph applies to all Macintosh models through the 
Macintosh Plus. Closing the serial driver on these machines kills 
mouse interrupts, since quadrature signals go to the SCC. 


Note: The Q & A Stack "Programming" section and Macintosh Technical Note #249 
contain a thorough discussion of opening and closing the ROM serial 
driver. 
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eeeClick on the X-Ref button, and refer to Technical Note #249 & Q & A Stack.eee 


To transmit serial data out through a port, make a Device Manager Write call to 
the output driver for the port. You must pass the following parameters: 


e the driver reference number —7 or —9, depending on whether you're using 
the modem port or the printer port 

¢ a buffer that contains the data you want to transmit 

e the number of bytes you want to transmit 


To receive serial data from a port, make a Device Manager Read call to the input 
driver for the port. You must pass the following parameters: 


e the driver reference number —6 or —8, depending on whether you're using 
the modem port or the printer port 

¢ a buffer to receive the data 

e the number of bytes you want to receive 


There are six different calls you can make to the Serial Driver's control 
routine: 


¢ KillIO causes all current I/0 requests to be aborted and any bytes 
remaining in both input buffers to be discarded. KillI0O is a Device 
Manager call. 

e SerReset resets and reinitializes a driver with new data bits, stop bits, 
parity bit, and baud rate information. 

e SerSetBuf allows you to specify a new input buffer, replacing the driver's 
64-character default buffer. 

e SerHShake allows you to specify handshake options. 

« SerSetBrk sets break mode. 

e SerClrBrk clears break mode. 


Advanced programmers can make nine additional calls to the RAM Serial Driver's 
control routine on 64K ROM machines and 14 additional calls on 128K ROM 
machines; see the "Advanced Control Calls" section. 


There are two different calls you can make to the Serial Driver's status 
routine: 


e SerGetBuf returns the number of bytes in the buffer of an input driver. 
e SerStatus returns information about errors, I/0 requests, and handshake. 


Assembly-language note: Control and Status calls to the RAM Serial Driver may 
be immediate (use IMMED as the second argument to the 
routine macro). 
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SERIAL DRIVER ROUTINES 


Most of the Serial Driver routines return an integer result code of type OSErr; 
each routine description lists all of the applicable result codes. 


Opening and Closing the RAM Serial Driver 
FUNCTION RAMSDOpen (whichPort: SPortSel) : OSErr; [Not in ROM] 


RAMSDOpen closes the ROM Serial Driver and opens the RAM input and output 
drivers for the port identified by the whichPort parameter, which must be a 
member of the SPortSel set: 


TYPE SPortSel = (sPortA, {modem port} 
sPortB {printer port}); 


RAMSDOpen determines what type of Macintosh is in use and chooses the RAM Serial 
Driver appropriate to that machine. 


Assembly-language note: To open the RAM input and output drivers from assembly 
language, call this Pascal procedure from your program. 


Result codes noErr No error 
openErr Can't open driver 


PROCEDURE RAMSDClose (whichPort: SPortSel); [Not in ROM] 


RAMSDClose closes the RAM input and output drivers for the port identified by 
the whichPort parameter, which must be a member of the SPortSel set (defined in 
the description of RAMSDOpen above). 


Warning: The RAM Serial Driver must be closed with a call to RAMSDClose 
before your application terminates. 


Assembly-language note: To close the RAM input and output drivers from 
assembly language, call this Pascal procedure from 
your program. 


Changing Serial Driver Information 


FUNCTION SerReset (refNum: INTEGER; serConfig: INTEGER) : OSErr; 
[Not in ROM] 


Assembly-language note: SerReset is equivalent to a Control call with 
csCode=8 and csParam=serConfig. 
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SerReset resets and reinitializes the input or output driver having the 
reference number refNum according to the information in serConfig. Figure 3 
shows the format of serConfig. 


is id 15 12 1110 9 Q 


a 
| 0, 1,2, 2for5, 7, 6,8 


data bits per character 


O, 1, 2, 3 for no odd, 
Lo, even parity 


1,2, 3 fori, 1.5,2 
stop hits 


Figure 3-Driver Reset Information 
Figure 3—Driver Reset Information 


You can use the following predefined constants to set the values of various bits 
of serConfig: 


CONST baud300 380; {300 baud} 


baud600 = 189; {600 baud} 
baud1200 = 94; {1200 baud} 
baud1800 = 62; {1800 baud} 
baud2400 = 46; {2400 baud} 
baud3600 = 30; {3600 baud} 
baud4800 = 22; {4800 baud} 
baud7200 = 14; {7200 baud} 
baud9600 - 10; {9600 baud} 
baud19200 = 4; {19200 baud} 
baud57600 = 0; {57600 baud} 
stop10 = 16384; {1 stop bit} 
stop15 = -32768; {1.5 stop bits} 
stop20 = -16384; {2 stop bits} 
noParity = 0; {no parity} 
oddParity = 4096; {odd parity} 
evenParity = 12288; {even parity} 
data5 = 0; {5 data bits} 
data6 = 2048; {6 data bits} 
data7 = 1024; {7 data bits} 
data8 = 3072; {8 data bits} 


For example, the default setting of 9600 baud, eight data bits, two stop bits, 
and no parity bit is equivalent to passing the following value in serConfig: 
baud9600 + data8 + stop20 + noParity. 


Result codes noErr No error 


Note: The Q & A Stack "Programming" section contains updated information 
on the 38,400 baud setting. 
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eeeClick on the X-Ref button, and refer to Q & A Stack,eee 


FUNCTION SerSetBuf (refNum: INTEGER; serBPtr: Ptr; 
serBLen: INTEGER) : OSErr; [Not in ROM] 


Assembly-language note: SerSetBuf is equivalent to a Control call with 
csCode=9, csParam=serBPtr, and csParam+4=serBLen. 


SerSetBuf specifies a new input buffer for the input driver having the reference 
number refNum. SerBPtr points to the buffer, and serBLen specifies the number of 
bytes in the buffer. To restore the driver's default buffer, call SerSetBuf with 
serBLen set to 0. 


Warning: You must lock a new input buffer while it's in use. 
Result codes noErr No error 
FUNCTION SerHShake (refNum: INTEGER; flags: SerShk) : OSErr; [Not in ROM] 


Assembly-language note: SerHShake is equivalent to a Control call with 
csCode=10 and csParam through csParam+6 flags. 


SerHShake sets handshake options and other control information, as specified by 
the flags parameter, for the input or output driver having the reference number 
refNum. The flags parameter has the following data structure: 


TYPE SerShk = PACKED RECORD 
fXOn: Byte; {XOn/XOff output flow control flag} 
fCTS: Byte; {CTS hardware handshake flag} 
xOn: CHAR; {XOn character} 
xOff: CHAR; {XOff character} 
errs: Byte; {errors that cause abort} 
evts: Byte; {status changes that cause events} 
fInX: Byte; {XOn/XOff input flow control flag} 
null: Byte {not used} 
END; 


If fXOn is nonzero, XOn/XOff output flow control is enabled; if fInX is nonzero, 
XOn/XOff input flow control is enabled. XOn and xOff specify the XOn character 
and XOff character used for XOn/XOff flow control. If fCTS is nonzero, CTS 
hardware handshake is enabled. The errs field indicates which errors will cause 
input requests to be aborted; for each type of error, there's a predefined 
constant in which the corresponding bit is set: 


CONST parityErr = 16; {set if parity error} 
hwOverrunErr = 32; {set if hardware overrun error} 
framingErr = 64; {set if framing error} 


Note: The ROM Serial Driver doesn't support XOn/XOff input flow control or 
aborts caused by error conditions. 


The evts field indicates whether changes in the CTS or break status will cause 
the Serial Driver to post device driver events. You can use the following 
predefined constants to set or test the value of evts: 
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CONST ctsEvent 
breakEvent 


32; {set if CTS change will cause event to be posted} 
128; {set if break status change will cause event } 
{ to be posted} 


Warning: Use of this option is discouraged because of the long time that 
interrupts are disabled while such an event is posted. 


Result codes noErr No error 
eeeClick on the X-Ref button, and refer to Technical Note #56.¢e¢¢ 
FUNCTION SerSetBrk (refNum: INTEGER) : OSErr; [Not in ROM] 


Assembly-language note: SerSetBrk is equivalent to a Control call with 
csCode=12. 


SerSetBrk sets break mode in the input or output driver having the reference 
number refNum. 


Result codes noErr No error 
FUNCTION SerClrBrk (refNum: INTEGER) : OSErr; [Not in ROM] 


Assembly-language note: SerClrBrk is equivalent to a Control call with 
csCode=11. 


SerClrBrk clears break mode in the input or output driver having the reference 
number refNum. 


Result codes noErr No error 


Getting Serial Driver Information 


FUNCTION SerGetBuf (refNum: INTEGER; VAR count: LONGINT) : OSErr; 
[Not in ROM] 


Assembly-language note: SerGetBuf is equivalent to a Status call with 
csCode=2; count is returned in csParam as a long word. 


SerGetBuf returns, in the count parameter, the number of bytes in the buffer of 
the input driver having the reference number refNum. 


Result codes noErr No error 


FUNCTION SerStatus (refNum: INTEGER; VAR serSta: SerStaRec) : OSErr; 
[Not in ROM] 


Assembly-language note: SerStatus is equivalent to a Status call with 
csCode=8; serSta is returned in csParam through 
csParam+5. 
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SerStatus returns in serSta three words of status information for the input or 
output driver having the reference number refNum. SerSta has the following data 
structure: 


TYPE SerStaRec = PACKED RECORD 


cumErrs: Byte; {cumulative errors} 

xOffSent: Byte; {XOff sent as input flow control} 

rdPend: Byte; {read pending flag} 

wrPend: Byte; {write pending flag} 

ctsHold: Byte; {CTS flow control hold flag} 

xOffHold: Byte {XOff flow control hold flag} 
END; 


CumErrs indicates which errors have occurred since the last time SerStatus was 
called: 


CONST swOverrunErr = 1; {set if software overrun error} 
parityErr = 16; {set if parity error} 
hwOverrunErr = 32; {set if hardware overrun error} 
framingErr = 64; {set if framing error} 


If the driver has sent an XOff character, xOffSent will be equal to the 
following predefined constant: 


CONST xOffWasSent = $80; {XOff character was sent} 

If the driver has a Read or Write call pending, rdPend or wrPend, respectively, 

will be nonzero. If output has been suspended because the hardware handshake was 
disabled, ctsHold will be nonzero. If output has been suspended because an XOff 

character was received, xOffHold will be nonzero. 


Result codes noErr No error 
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ADVANCED CONTROL CALLS 


This section describes several advanced control calls. Control calls to the 
Serial Driver should be made to the output character channel driver. 


csCode = 13 csParam = baudRate 

This call provides an additional way (besides SerReset) to set the baud rate. 
CsParam specifies the actual baud rate as an integer (for instance, 9600). The 
closest baud rate that the Serial Driver will generate is returned in csParam. 
csCode = 19 csParam = char 

After this call is made, all incoming characters with parity errors will be 
replaced by the character specified by the ASCII code in csParam. If csParam is 
0, no character replacement will be done. 

csCode = 21 

This call unconditionally sets XOff for output flow control. It's equivalent to 
receiving an XOff character. Data transmission is halted until an XOn is 
received or a Control call with csCode=24 is made. 

csCode = 22 


This call unconditionally clears XOff for output flow control. It's equivalent 
to receiving an XOn character. 


csCode = 23 


This call sends an XOn character for input flow control if the last input flow 
control character sent was XOff. 


csCode = 24 


This call unconditionally sends an XOn character for input flow control, 
regardless of the current state of input flow control. 


csCode = 25 


This call sends an XOff character for input flow control if the last input flow 
control character sent was XOn. 


csCode = 26 


This call unconditionally sends an XOff character for input flow control, 
regardless of the current state of input flow control. 


csCode = 27 
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This call lets you reset the SCC channel belonging to the driver specified by 
ioRefNum before calling RAMSDClose or SerReset. 


Note: The extensions to the Serial Drivers described in the following 
paragraphs were originally documented in Inside Macintosh, Volume IV. 
As such, this information refers to the 128K ROMs and System file 
version 3.2 and later. 


csCode = 14 csParam through csParam+7 = serShk 


This call is identical to a control call with csCode=10 (the SerHShake function, 
described above) with the additional specification of the DTR handshake option 
in the eighth byte of its flags parameter (the null field of the SerShk record). 
You can enable DTR input flow control by setting this byte to a nonzero value. 
This works symmetrically to hardware handshake output control. 


csCode = 16 csParam = byte 


This call sets miscellaneous control options. Bits 0-6 should be set to 0 for 
future options. Bit 7, if set to 1, will cause DTR to be left unchanged when the 
driver is closed (rather than the normal procedure of negating DTR). This may be 
used for modem control to prevent the modem from hanging up just because the 
driver is being closed (such as when the user temporarily exits the terminal 
program). 


csCode = 17 

This call asserts DTR. 

csCode = 18 

This call negates DTR. 

csCode = 20 csParam = char csParam+1 = alt char 

This call is an extension of call 19, which would simply clear bit 7 of an 
incoming character when it matched the replacement character. After this call is 
made, all incoming characters with parity errors will be replaced by the 
character specified by the ASCII code in csParam. If csParam is 0, no character 
replacement will be done. If an incoming character is the same as the 
replacement character specified in csParam, it will be replaced instead by the 
second character specified in csParam+l. 


Note: With this call, the null character (ASCII $00) can be used as the 
alternate character but not as the first replacement. 


@ SpInside Macintosh * Version 1.0 * November 1989 * Apple Computer 
THE SERIAL DRIVERS ¢« 15 of 20 


SUMMARY OF THE SERIAL DRIVERS 


Constants 
CONST 


{ Driver reset information } 


baud300 = 380; {300 baud} 
baud600 = 189; {600 baud} 
baud1200 = 94; {1200 baud} 
baud1800 = 62; {1800 baud} 
baud2400 = 46; {2400 baud} 
baud3600 = 30; {3600 baud} 
baud4800 = 22; {4800 baud} 
baud7200 = 14; {7200 baud} 
baud9600 = 10; {9600 baud} 
baud19200 = 4; {19200 baud} 
baud57600 = 0; {57600 baud} 
stop10 = 16384; {1 stop bit} 
stop15 = -32768; {1.5 stop bits} 
stop20 = -16384; {2 stop bits} 
noParity = 0; {no parity} 
oddParity = 4096; {odd parity} 
evenParity = 12288; {even parity} 
data5 = 0; {5 data bits} 
data6 = 2048; {6 data bits} 
data7 = 1024; {7 data bits} 
data8 = 3072; {8 data bits} 


{ Masks for errors } 


swOverrunErr = 1; {set if software overrun error} 
parityErr = 16; {set if parity error} 
hwOverrunErr = 32; {set if hardware overrun error} 
framingErr = 64; {set if framing error} 


{ Masks for changes that cause events to be posted } 


ctsEvent 
breakEvent 


32; {set if CTS change will cause event to be posted} 
128; {set if break status change will cause } 
{ event to be posted} 


{ Indication that DTR is negated } 
dtrNegated = $40; {[Volume IV addition] } 
{ Indication that an XOff character was sent } 


xOf fWasSent = $80; 
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{ Result codes } 


0; {no error} 
-23; {attempt to open RAM Serial Driver failed} 


noErr 
openErr 


{ Result codes [Volume IV additions]} 


portInUse = -97; {driver Open error, port already in use} 
portNotCf = -98; {driver Open error, port not configured for this } 
{ connection} 
memFullErr = —108; {not enough room in heap zone} 
Data Types 
TYPE 


SPortSel = (sPortA, {modem port} 
sPortB {printer port}); 


SerStaRec = PACKED RECORD 


cumErrs: Byte; {cumulative errors} 

xOffSent: Byte; {XOff sent as input flow control} 

rdPend: Byte; {read pending flag} 

wrPend: Byte; {write pending flag} 

ctsHold: Byte; {CTS flow control hold flag} 

xOffHold: Byte {XOff flow control hold flag} 
END; 


SerShk = PACKED RECORD 
fXOn: Byte; {XOn/XOff output flow control flag} 
fCTS: Byte; {CTS hardware handshake flag} 
xOn: CHAR; {XOn character} 
xOff: CHAR; {XOff character} 
errs: Byte; {errors that cause abort} 
evts: Byte; {status changes that cause events} 
fInX: Byte; {XOn/XOff input flow control flag} 
null: Byte {not used} 
END; 


{[Volume IV addition] } 


SerShk = PACKED RECORD 
fXOn: Byte; {XOn/XOff output flow control flag} 
fCTS: Byte; {CTS hardware handshake flag} 
xOn: CHAR; {XOn character} 
xOff: CHAR; {XOff character} 
errs: Byte; {errors that cause abort} 
evts: Byte; {status changes that cause events} 
fInX: Byte; {XOn/XOff input flow control flag} 
fDTR: Byte {DTR input flow control flag} 
END; 
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Routines 
Opening and Closing the RAM Serial Driver 


FUNCTION RAMSDOpen (whichPort: SPortSel) : OSErr; 
PROCEDURE RAMSDClose (whichPort: SPortSel); 


Changing Serial Driver Information 


FUNCTION SerReset (refNum: INTEGER; serConfig: INTEGER) : OSErr; 
FUNCTION SerSetBuf (refNum: INTEGER; serBPtr: Ptr; 

serBLen: INTEGER) : OSErr; 
FUNCTION SerHShake (refNum: INTEGER; flags: SerShk) : OSErr; 
FUNCTION SerSetBrk (refNum: INTEGER) : OSErr; 
FUNCTION SerClrBrk (refNum: INTEGER) : OSErr; 


Getting Serial Driver Information 


FUNCTION SerGetBuf (refNum: INTEGER; VAR count: LONGINT) : OSErr; 
FUNCTION SerStatus (refNum: INTEGER; VAR serSta: SerStaRec) : OSErr; 


Advanced Control Calls (RAM Serial Driver) 


csCode csParam Effect 
13 baudRate Set baud rate (actual rate, as an integer) 
19 char Replace parity errors 
21 Unconditionally set XOff for output flow control 
22 Unconditionally clear XOff for input flow control 
23 Send XOn for input flow control if XOff was sent last 
24 Unconditionally send XOn for input flow control 
25 Send XOff for input flow control if XOn was sent last 
26 Unconditionally send XOff for input flow control 
27 Reset SCC channel 


Volume IV additions 


csCode csParam Effect 
14 serShk Set handshake parameters 
16 byte Set miscellaneous control options 
17 Asserts DIR 
18 Negates DIR 
20 2 chars Replace parity errors, with alternate 


replacement character 


Driver Names and Reference Numbers 
Driver Driver name Reference number 


Modem port input .AIn -6 
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Modem port output .AOut -7 
Printer port input .BIn -8 
Printer port output .BOut -9 


Assembly-Language Information 
Constants 
; Result codes 


noErr .EQU 0 ;no error 
openErr -EQU = —23 ;attempt to open RAM Serial Driver failed 


; [Volume IV additions] 


portInUse .EQU -97 ;driver Open error, port already in use 

portNotCf . EQU -98 ;driver Open error, port not configured 
;for this connection 

memFullErr EQU -108 ;not enough room in heap zone 


Structure of Status Information for SerStatus 


ssCumErrs Cumulative errors (byte) 
ssxOffSent XOff sent as input flow control (byte) 
ssRdPend Read pending flag (byte) 
ssWrPend Write pending flag (byte) 


ssCTSHold CTS flow control hold flag (byte) 
ssxXOffHold XOff flow control hold flag (byte) 


Structure of Control Information for SerHShake 


ShFXOn XOn/XOff output flow control flag (byte) 
ShFCTS CTS hardware handshake flag (byte) 


shxOn XOn character (byte) 

shxOf f XOff character (byte) 

shErrs Errors that cause abort (byte) 

shEvts Status changes that cause events (byte) 
shFInX XOn/XOff input flow control flag (byte) 
shDTR DTR control flag (byte) [Volume IV addition] 


Equivalent Device Manager Calls 


Pascal routine Call 

SerReset Control with csCode=8, csParam=serConfig 

SerSetBuf Control with csCode=8, csParam=serBPtr, csParam+4=serBLen 
SerHShake Control with csCode=10, csParam through csParam+6=flags 
SerSetBrk Control with csCode=12 

SerClrBrk Control with csCode=11 

SerGetBuf Status with csCode=2; count returned in csParam 

SerStatus Status with csCode=8; serSta returned in csParam 


through csParam+5 
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Further Reference: 


Resource Manager 

Toolbox Event Manager 

Memory Manager 

Device Manager 

Technical Note #2, Compatibility Guidelines 
Technical Note #10, Pinouts 

Technical Note #56, Break/CTS Device Driver Event Structure 
Technical Note #65, Macintosh Plus Pinouts 
Technical Note #117, Compatibility: Why & How 
Technical Note #212, The Joy Of Being 32-Bit Clean 
Technical Note #249, Opening the Serial Driver 

Q & A Stack 

"Macintosh Family Hardware Reference" 


END OF DOCUMENT 
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